Software Vault: The Gold Collection/Software Vault - The Gold Collection (American Databankers) (1993).ISO/cdr47/x.zip/X.DOC

Text File | 1993-01-30 | 5KB | 108 lines

    Keyboard Xtender V1.0

    X.SYS is a keyboard buffer extender program.  This program extends
    the keyboard buffer from 16 keystrokes to 256 keystrokes.  No longer
    will you have to listen to the "beep-beep-beep" when your keyboard
    buffer is full!

    This program is a device driver that should be loaded in your
    CONFIG.SYS file.  Copy X.SYS to your root directory.  You should
    make a bootable floppy disk just in case X.SYS causes problems on
    your machine.  If your machine locks up, you can boot off of the
    floppy drive and remove X.SYS from your CONFIG.SYS file.  To install
    X.SYS, add the following line to your CONFIG.SYS file:

         DEVICE=C:\X.SYS

    That's all there is to it!  When you reboot your machine you will
    see a status message indicating the Keyboard Xtender was loaded.

    Note: Because of the way that X.SYS works, you cannot load X.SYS
          into high memory.  But hey, the program is only 775 bytes
          long so it won't chew up too much of the precious 640K of RAM.


    X.SYS is Snareware, once you try it you're hooked!


    Now for the legal mumbo-jumbo:

    Limitation of Liability.  In no event shall I be liable for any
    incidental, consequential, or punitive damages whatsoever arising
    out of use of this Keyboard Xtender software (X.SYS), including
    without limitation any or all damages for loss of profits, business
    interruption, loss of information, or any pecuniary loss, even if
    I have been advised of the possiblity of such damages.


    To build X.SYS just assemble X.ASM (I used Turbo Assembler), then
    link the object file to produce an X.EXE file (Tlink works nice).
    Use EXE2BIN to convert the EXE file to a SYS binary file.


    "Gee!, Mr. Wizard, how does it work?"

    "Well Johnny, normally your keyboard buffer occupies a 32 byte portion
    of low memory in the BIOS memory segment (segment 40 hex).  The buffer
    usually resides at 40:1E through 40:3D.  These 32 bytes create a
    circular queue that the keyboard interrupt routine in ROM uses to store
    any character received from the keyboard.  The buffer actually contains
    the scan code and the character code for each character entered on the
    keyboard.  That's why you only get 16 characters from a 32 byte buffer."

    "The BIOS read keyboard interrupt routine reads this buffer when programs
    are waiting for keyboard input.  Also stored in the BIOS memory segment
    are the head and tail pointers for this circular keyboard buffer (at
    40:1A and 40:1C, respectively).  These head and tail pointers point to
    the buffer position of any characters that have been received from the
    keyboard but have not been read by an application yet.  When the head
    and tail pointers are the same, the buffer is empty.  When the head
    pointer is one position less than the tail pointer, the buffer is full.
    If you try to enter keystrokes when the buffer is full, you get the
    "beep-beep-beep" sound from the BIOS keyboard interrupt routine."

    "What we want to do is expand this keyboard buffer to allow more
    keystrokes to be entered while the computer is processing previous
    commands.  There are two methods of doing this, the hard way, and
    the easy way.  Programmers (i.e. Hackers), like myself, basicly being
    lazy, will choose to do things the easy way.  The hard way involves
    writing a TSR that handles the BIOS keyboard interrupt routine function
    and the BIOS read keyboard interrupt routine function and expanding the
    buffer they use to a larger size.  This is too much like work!"

    "The normal BIOS keyboard interrupt routine and the BIOS read keyboard
    interrupt routine unfortunately assume that the keyboard buffer is
    ALWAYS going to exist in the BIOS memory segment (40 Hex).  This causes
    a problem when you try to load a TSR that allocates more space for the
    keyboard buffer, because by the time DOS and COMMAND.COM get loaded
    (pun intended!), the next available memory is well beyond the 40 hex
    BIOS memory segment.  We need a way to allocate some memory before
    COMMAND.COM chews up it's memory."

    "We can do this by using a device driver!"

    "But Mr. Wizard, I thought device drivers were only used to talk to
    physical or virtual devices.  And you said you didn't want to rewrite
    the BIOS keyboard routines!"

    "You're right Johnny!  Device drivers normally are used to talk to
    physical or virtual devices, but in this case all we want to do is
    allocate a block of memory for the new keyboard buffer and modify
    the BIOS memory segment keyboard head and tail pointers to point to
    this new block.  We also have to update the start of buffer and end
    of buffer addresses in the BIOS memory segment (at 40:80 and 40:82
    respectively).  These start and end addresses tell the BIOS keyboard
    routines where the buffer begins and ends in memory so that when the
    head or tail is incremented, they will wrap around from the end of
    the buffer back to the beginning of the buffer, hence the name
    'circular queue'.  That's all there is to it!"


    "Oh!, I see!  Well gee, Mr. Wizard!  Why does my tongue stick to a
    metal flag pole on a cold winter day?"

    "Well, Johnny....."

    (to be continued)